現在 AI 寫程式越來越快，我真正擔心的，其實不是未來的工程師不會寫 Code。因為有一天，Code 可能真的不需要人自己一行一行寫了。真正值得擔心的是，當 AI 可以完成大部分 Coding 之後，我們還有沒有足夠的人，知道 AI 寫出來的東西到底對不對？這可能會形成另一種人才斷層。

以前為了解決一個問題，我們通常得先把問題弄懂。為什麼資料庫會 Lock？為什麼 Connection 沒有 Release？為什麼一段 SQL 在一萬筆資料時看不出問題，到了百萬筆就開始變慢？為什麼某個 Function 不該放在這一層？為什麼兩個 Module 不應該直接相依？甚至為什麼明明套用了 Design Pattern，系統反而變得更難維護？這些東西很多不是單純看書就能真正理解，而是一次一次寫錯、Debug、重構、上線、出問題，再回頭修正，慢慢累積出來的。

但 AI 正在把這中間很多過程壓縮掉。現在很容易變成「需求 → Prompt → AI 產生程式 → Demo 跑起來 → 完成」。問題是，功能完成和軟體工程完成，從來不是同一件事情。同一個需求可以有很多種做法，而且很多做法都可以正常執行，Demo 看起來也都沒有問題，但不代表每一種都是好的設計。

AI 可以根據它知道的資訊，告訴你它認為最適合的做法，但問題在於，它知道的 Context 真的完整嗎？現在只有一萬筆資料，未來也許是一千萬筆；現在只有二十個人使用，未來也許會有兩千個人同時上線；現在系統都在公司內網，之後可能要跨國、跨廠區，還要面對 VPN、頻寬、網路延遲與不同環境的限制。

更麻煩的是，有很多真正影響系統設計的事情，根本沒有寫在文件裡。某個 Legacy System 有特殊限制，某個廠區網路品質一直不穩，某個系統每天固定時間會跑大量 Batch，某些流程文件上的 SOP 是這樣，但使用者實際工作的方式根本不是這樣。這些事情，往往只有真正待在這家公司、做過這些系統、處理過這些問題的人才知道。

所以 AI 有可能把功能完成了，程式本身也沒有明顯錯誤，但方向卻是錯的。而軟體工程裡最麻煩的，往往就是這種錯誤。因為它不是今天 Compile 不過，也不是 Demo 當場爆掉，它可能半年後才開始出現問題，甚至兩三年後，當資料量、使用人數、系統整合越來越複雜，大家才發現當初某個 Architecture Decision 已經讓整套系統很難再往下走。

如果是一個有經驗的工程師在使用 AI，這個風險相對還比較能控制。因為看到 AI 產生的程式，我們多少會開始去想：這裡為什麼要這樣切？為什麼多這一層？Transaction 的邊界在哪裡？Exception 怎麼處理？這個 Query 資料量放大之後會怎樣？Concurrency 怎麼處理？Security 是真的做到 Backend，還是只是前端把按鈕藏起來？這個架構三年後還維護得下去嗎？

這些問題，其實就是過去經驗累積下來的判斷力。

但如果一個人從來沒有真正寫過程式，沒有 Debug 過、沒有設計過架構，也沒有經歷過系統上線之後出問題的過程，他很可能連「這裡應該有問題」都不會察覺，更不用說知道下一步應該問什麼。

所以我真正擔心的，不是 AI 會不會寫錯程式。真正可怕的是，AI 寫錯了，而使用 AI 的人沒有能力知道它錯了。更麻煩的是，有時候它甚至不是「寫錯」，它只是做了一個現在可以運作、長期卻不適合的決定，而這種錯誤通常也是最貴的。

這也是我認為 AI 時代在軟體工程上最值得注意的一件事。未來真正稀缺的，可能不是「會不會把程式寫出來」，而是有沒有能力判斷什麼才是好的程式、什麼才是好的架構，以及什麼東西其實從一開始就不應該這樣做。